The diagram above illustrates the new XFaceMaker 3.0 architecture. It consists of two processes - the Main process and the Design process - communicating through a network communication protocol.
The Main process manages XFaceMaker's own GUI, i.e., the XFaceMaker main window, editing windows, dialog boxes, etc. and the behavior associated with them. The XFaceMaker process also memorizes the editing state of the design process so that it can restore it when an error occurs or when the design process is restarted.
The Design process creates the interface being designed and executes the FACE scripts written by the designer. The design process also handles some of the editing commands and feedback, like saving and loading the interface files, drawing the selection handles, applying templates, etc.
With the XFaceMaker extension mechanism, the design process can be linked with the whole application code, allowing the application functions to be tested while designing the interface. Since the design process can be launched while XFaceMaker is running, this feature allows the developer to modify, compile and restart the application code as many times as required without exiting XFaceMaker.
The two processes communicate through a UNIX socket and use a communication protocol implemented by the FACE interpreter. The FACE protocol allows two processes running a FACE interpreter to communicate through FACE function calls and through global active value calls.
Automatic error recovery
Error protection is the first major functionality offered by the dual-process mode. In most UIMS's, as in previous versions of XFaceMaker, the interface and its behavior are implemented in the same process as the editor itself. As a result when the GUI being designed crashes, the whole tool crashes. Thus all single process GUI builders are inherently fragile and subject to crashes caused by the GUI developer.
The standard remedy has been to check for all cases that may cause the GUI to crash. This is at best unsatisfactory, since it requires thousands or tens of thousands of checks and add an extremely high overhead. Furthermore, it is practically impossible to guarantee that all cases have been checked.
XFaceMaker 3.0 solves this problem by separating the interface being designed from the editor itself. Hence, in XFaceMaker 3.0, the Design process can crash, but the XFaceMaker Main process stays alive.
When a fatal error occurs in the user's interface, the Design process terminates. On termination, the nature of the error is displayed in the XFaceMaker message box and an alert is issued to the user. In most cases, one just needs to click 'OK' to restart the design process.
XFaceMaker keeps a copy of the state of the Design process and on restoring, this copy is given to the starting Design process which will restart where the old one had stopped.
It may happen that the design process state cannot be saved before it exits, for example if the data is too corrupted. For this reason, XFaceMaker keeps a second security state called the 'trusted state', which is saved periodically every 30 seconds and every time the user switches to Try mode. It is also possible to save the state to disk, as a protection against other type of failures.
Launching a new Design process
The user can control the Design process through the 'Restart Design Process' command. This will start a different Design process and gives access to the 'Dynamic Extension' functionality of XFaceMaker.
For example, suppose you wanted to define a new C function and add it to XFaceMaker so that it can be called in a FACE script. As before, you will have to write your function, compile it and link it with a main program containing the relevant calls. (In fact, XFaceMaker 3.0 will do everything - except writing the function - automatically). The difference is that you don't have to exit your current XFaceMaker and start a new one from the beginning. Instead, you use the 'Restart Design Process' command, specify the new program as the design process and your new function is available.
